有關於實際業務上對於數據要求的重要性，以下參數設定的寫入策略搭配會對性能與安全度產生不同的影響。

相關參數內容:

innodb_flush_log_at_trx_commit

• 控制日誌緩衝區內容如何寫入和刷新到磁盤策略參數: innodb_flush_log_at_trx_commit (選項: 0,1,2)

看一下大致流程，才會懂下面提到的參數設置意義喔！！

(內存中的日誌緩衝)                                        (磁盤上)        
redo log buffer -寫入-> OS cache  --呼叫fsync()刷盤--> redo log file 

ps. 呼叫fsync()操作指的是將OS buffer中的日誌刷到磁碟上的redo log file中數據持久化。

設 0 - 每隔1秒才將日誌緩存區中的日誌寫入到os cache並呼叫fsync()刷新到磁盤上的redo log file。

(雖然效率高但資料安全性低，因為1秒的數據有可能因為mysql崩潰而丟失)

設 1 - 每次事務提交時都會將日誌緩存區中的日誌寫入os cache並呼叫fsync()刷新到磁盤上的redo log file。

(資料安全性高，因為只要提交就會更新磁盤資料所以不會有丟失的狀況，不過因為每次提交都刷新磁盤所以效能相對最差)

設 2 - 每次事務提交時把日誌緩存區的日誌寫入os cache，不會同時刷新到磁盤上，而是每秒呼叫fsync()刷到磁盤上的redo log file。

(比設為0安全每秒執行刷新到磁盤，在操作系統崩潰or系統斷電的狀況下才可能發生那一秒的數據丟失)

sync_binlog

• 控制MySQL服務器將binlog同步到磁盤的頻率: sync_binlog (選項: 0,1,N個)

寫入流程如下，先了解才會懂下面提到的參數設置意義喔！！

                                         事務提交(commit)
事務執行中(尚未commit) -寫入-> binlog cache -----寫入-----> os cache -呼叫fsync()刷盤--> binlog

設 0: 在事務提交時不會將二進制日誌同步到磁盤。(等於不會fsync()刷盤)

設 1: 在事務提交時會將二進制日誌同步到磁盤。(最安全的設置，且保證沒有事務從二進制日誌中丟失)

設 N(>1): 當提交的日誌組到達設定值N時，會將二進制日誌同步到磁盤。

• 如何去取捨兩者參數之間的搭配有關於:

  • 對數據安全性要求(高低)
  • 磁盤寫入能力(好壞)
  • 主從延遲落後問題

下集預告: 了解完以上內容後明天就正式講解二階段提交流程囉！